fix(prose-tests): command output was never actually recorded#560
Open
leeovery wants to merge 1 commit into
Open
fix(prose-tests): command output was never actually recorded#560leeovery wants to merge 1 commit into
leeovery wants to merge 1 commit into
Conversation
The recorder has been reading `tool_output` off a post-tool payload. The field is `tool_response`, and for a shell it is an object of `stdout` and `stderr` rather than a string — so every successful call recorded its status and nothing else. Rows read `→ ok` with an empty output column. That silence undercut the one thing the record exists for. The asserter is told a claim about what a command produced — that a gate rendered empty, that a menu had no entries — is settled by the record rather than by the walker's account of it. It could not be. With no output there, a claim about output had only the narrative to rest on, which is precisely the evidence the record was introduced to replace. Output now comes from `tool_response`, reading a shell's streams directly so a command's output stays legible as output instead of a JSON envelope around it, and a command gets far more room than a file read: a claim turns on a rendered section surviving whole, never on the bytes a walker read back. Also drops the `tool_output_is_error` check, which never fired and never could. A failing call does not reach PostToolUse at all — it raises PostToolUseFailure, which was already recording correctly — so arriving here is itself the success signal. Verified against a live walk: the gateway's DATA, DISPLAY and MENU sections now all appear in the record, menu entries included. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Jul 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
tool_outputoff a post-tool payload; the field istool_response, and for a shell it's an object ofstdout/stderr, not a string. Every successful call therefore recorded its status and nothing else — rows read→ okwith an empty output column.tool_output_is_errorcheck — it never fired and never could. A failing call doesn't reachPostToolUse; it raisesPostToolUseFailure, which was already recording correctly. Reaching the success branch is itself the signal.Test plan
node --test tests/scripts/test-prose-record-action.cjs— 17/17, with five new cases: stdout capture, stderr merging, the command-vs-read budget split, a non-shell response shape, and the failure path→ okand nothing more.Why it matters beyond the bug
Steps about display and menus could previously only be evidenced from the walker's narrative. In a Sonnet-walker trial, one case passed cleanly and another failed purely because its narrative was thin — the recorded actions proved the work was done. With output in the record, that evidence moves off the narrative, which is the precondition for revisiting the walker model.
🤖 Generated with Claude Code
Stack